… jar (#4929)

* Fix CSSWatcher live reload: drop stale bindings + extract m2 designer jar

Two recent CSS/localization changes regressed the simulator's live CSS
reload, in different ways.

1. addThemeProps stomped user edits with stale @cn1-bind entries.
   PR #4884 added applyThemeBindings() inside UIManager.buildTheme so a
   single addThemeProps({"@accent-color": ...}) override could retune
   every var()-bound theme key. But CSSWatcher reloads the theme through
   the same code path -- and addThemeProps never clears themeConstants.
   When the user replaced a `var()` rule with a literal in their CSS,
   the recompiled theme.res no longer emitted the matching
   `@cn1-bind:<key>` entry, but the previous binding was still sitting
   in themeConstants. applyThemeBindings happily re-overlaid the
   user's fresh literal value with the stale binding's resolved value,
   so the visible change disappeared on every reload.

   Fix: in buildTheme, before iterating the incoming Hashtable, detect
   any binding whose subject style key the new load is re-setting
   without re-asserting the binding alongside, and drop those bindings
   before the overlay pass runs. Pure `@accent-color` overrides keep
   working because they don't carry style keys, so no bindings are
   considered stale.

2. MavenUtils.findDesignerJarInM2 returned the unrunnable wrapper zip.
   PR #4852 added an m2 fallback for the CSSWatcher's designer-jar
   lookup, used whenever -Dcodename1.designer.jar isn't passed in (e.g.
   simulator launched from the IDE rather than `mvn cn1:run`). The
   helper returned `codenameone-designer-<v>-jar-with-dependencies.jar`
   directly from m2 -- but that artifact is a zip wrapper containing a
   single inner designer_1.jar (see maven/designer/pom.xml's antrun
   step), with no top-level Main-Class manifest. `java -jar wrapper.zip`
   fails with "no main manifest attribute", the CSS subprocess never
   starts, and the watcher silently waits for ::refresh:: lines that
   never come.

   Fix: mirror AbstractCN1Mojo.getDesignerJar's pattern -- unzip the
   wrapper to an `<artifact>.jar-extracted/` sibling on demand and
   return the inner designer_1.jar so `java -jar` actually launches.

Tests:

- UIManagerThemeBindingsTest gains three regression cases:
  cssReloadDropsStaleBindingWhenRuleBecomesLiteral (the actual
  reproducer), cssReloadKeepsBindingWhenStillEmittedTogether (guard
  against an over-eager fix), and overrideOnlyReloadKeepsBindings
  (repeated `@accent-color` retunes still work). The first fails
  before the UIManager fix; all three pass after.

- MavenUtilsTest is new and covers the wrapper-vs-inner-jar resolution
  with five cases: happy path, re-use of extracted inner jar when the
  wrapper hasn't changed, re-extract when the wrapper mtime advances,
  null when the core jar isn't in an m2 layout, and null when the
  designer artifact is missing. To make these actually executable, the
  javase pom now pins maven-surefire-plugin to 3.2.5 (the parent's
  2.21.0 doesn't auto-discover JUnit Jupiter). The pre-existing
  CSSWatcherTest + LocationSimulationTest + JavaSEPortFontMappingTest
  in the same module also start running as a side effect.

- pr.yml gets a new "Run JavaSE port unit tests" step so this whole
  test class -- which compiled but never executed -- is wired into CI.
  Without it, regressions in CSSWatcher/MavenUtils/JavaSEPort helpers
  would continue to slip through, which was the original gap the user
  flagged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Address PR review: harden Zip Slip + install javase deps in CI step

- MavenUtils.extractInnerJar no longer derives a File path from
  ZipEntry.getName(). CodeQL flagged the previous loop as a Zip Slip
  risk because a wrapper containing `../../etc/passwd` would have been
  written outside the extraction directory. The wrapper produced by
  maven/designer/pom.xml has a single designer_1.jar entry by design,
  so the extractor now (a) writes only to a single fixed destination
  path under destDir and (b) only matches entries whose literal name
  equals "designer_1.jar". Anything else is skipped; if the canonical
  entry is absent, the method throws. Two new MavenUtilsTest cases:
  refusesPathTraversalEntriesAndDoesNotWriteOutsideExtractDir packs a
  `../../escaped.txt` entry and asserts no escaped file appears in the
  temp root; skipsUnexpectedEntriesAndStillExtractsDesignerJar mixes
  a README and a subdir/other.jar with the real designer_1.jar and
  asserts only the inner jar lands on disk.

- pr.yml's new "Run JavaSE port unit tests" step failed with
  "Could not find artifact com.codenameone:sqlite-jdbc:jar:8.0-SNAPSHOT"
  on all three matrix entries (Java 8/17/21). The earlier "Build
  Codename One" step builds core-unittests with -am, which doesn't
  install sqlite-jdbc into the local repo. Split the new step into
  two mvn invocations: first install javase's transitive deps without
  running their tests, then run javase's tests in isolation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* UIManager: scope stale-binding drop to addThemeProps, fix iOS hang

The previous fix ran the stale-binding preprocessing inside buildTheme,
which is also called from the @includeNativeBool layered initial load
(setThemePropsImpl -> buildTheme -> Display.installNativeTheme() ->
buildTheme(native) -> outer buildTheme(userTheme) continues). After the
native theme installs its bindings into themeConstants, the outer call's
preprocessing would drop them whenever the user's app theme.css set a
literal value for the same UIID -- which the existing iOS / Android
screenshot goldens were captured against.

The iOS PR check hit this: the device-runner log shows the suite ran
fine through ChartCubicLineScreenshotTest and then hung in
ChartBarScreenshotTest setup until the 30-minute timeout fired. The
inconsistent themeConstants state left over once the layered native
bindings were dropped manifests as a hang in chart-component initialization
(presumably a Style.derive cycle or similar) rather than as a pixel
diff.

Move the drop pre-pass out of buildTheme and into a new
dropSupersededBindings() called only from addThemeProps. This keeps
the CSSWatcher reload fix (the actual reported regression) and the
companion regression tests passing, while restoring the original
behavior of the layered initial-load path -- bindings declared by the
native theme via @includeNativeBool stay live, user-app literals don't
silently strip them out.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>